The _n_e_w_a_r_r_a_y_s_e_s_s function creates a new array session and moves the
current process from its original array session to the new one. The
parents, children and siblings of the current process are not affected by
this and remain in their original array sessions.
A handle for the new array session will be generated by the system.
Normally the new handle is guaranteed to be unique on the current system
only, though some systems may be able to assign global array session
handles that are unique across an entire array of systems by setting the
aaaassssmmmmaaaacccchhhhiiiidddd system variable. Otherwise, the range of values that the system
may assign for array session handles is defined by the system variables
mmmmiiiinnnn____llllooooccccaaaallll____ppppaaaaggggggggiiiidddd and mmmmaaaaxxxx____llllooooccccaaaallll____ppppaaaaggggggggiiiidddd. System variables can be examined
and/or modified with _s_y_s_t_u_n_e(1). If necessary, the _s_e_t_a_s_h(2) function
can be used to override the default handle after the array session has
been created.
The project ID and service provider information for the new array session
are taken from the original array session of the current process. They
can be changed after the new array session has been created using the
_s_e_t_p_r_i_d(2) and _s_e_t_s_p_i_n_f_o(2) functions.
For the purposes of array session accounting, it is undefined whether the
resources used by the current process are charged to the original array
session, the new array session, or split between both in some fashion.
It _i_s guaranteed that the process resources will be charged to at least
one of the two array sessions, and that if the resources are split
between the two array sessions, they will be split cleanly (in other
words, no "double-billing" will take place).
Ordinarily, a new array session should be started whenever the conceptual
equivalent of a login is performed. This would include programs that do
conventional logins (for example, _l_o_g_i_n(1) or _t_e_l_n_e_t(1)) as well as
programs that are essentially "logging in" to do work on behalf of
another user, such as _c_r_o_n(1) or batch queueing systems.
Using the _a_r_s_o_p(2) function, it is possible to restrict the processes in
an array session from starting a new array session. If this has been
done, then _n_e_w_a_r_r_a_y_s_e_s_s will fail with an EEEEPPPPEEEERRRRMMMM error.
EEEERRRRRRRROOOORRRRSSSS
_n_e_w_a_r_r_a_y_s_e_s_s may fail if the following condition is true: